In the software industry, it is often desirable to limit access to a given software application for reasons that may include preventing unauthorized use (e.g., unlicensed pirating) or unauthorized manipulation (e.g., hacking). One known solution to unauthorized use of software is to bind any given software application to a specific computer or device. In this manner, the software application may then only be executed on the respective licensed device. This binding of the software application to a specific device is commonly known as node-locking or alternatively referred to as hardware-software anchoring.
The traditional approach to node-locking has been to take a unique identifier (ID) from a piece of hardware and make the software application dependent on the given ID. The number and characteristics of these unique IDs vary greatly from platform to platform. Some common hardware identifiers include: the Media Access Control (MAC) address, the Hard-Disk Drive Identifier (HDD ID), and a Serial Number (SN). Additional node-locking identifiers can include Basic Input/Output System (BIOS) values, hash values computed by a driver hash function, device IDs, or any similar identifier unique to a given hardware device or element. In the traditional approach to node-locking, anchoring a piece of software (i.e. the application) to a particular node is a matter of creating a dependency from the unique ID to the functioning of the software. In some systems, this may be a set of mathematical operations that derive a key from a unique ID. In other systems, an algorithm may be devised that requires a subset of unique IDs to be valid while allowing all others to be incorrect. The latter allows for variation in the hardware itself—for example, a network interface card may be removed from a computer.
In a white-box attack context, the attacker has full knowledge of the system being attacked and therefore full control over the execution of the software. The attacking intruder may or may not be a legitimate user of the software, though the execution of the software is assumed to proceed normally. There are many difficulties with the security of the traditional approach to node-locking in a white-box attack scenario. The hardware IDs must typically be read during execution, and this characteristic therefore makes them easy to replicate. A variety of these types of white-box attacks follow.
In one scenario, at the point where the software application calls the Application Programming Interface (API) which queries the unique ID of the device, an attacker may replace this call with a hard-coded value. This may be a function that the attacker replaces in the software application code itself, or it could simply be the data area where the software application is expecting to obtain the ID. If the attacker can mount this attack, he can replace the unique ID with any chosen value, thereby rendering the node-locking protection ineffective. Further, a typical extension of hard-coding attacks is the creation of an exploit. As an attacker learns where to hard-code an important value, he also becomes enabled in creating an automatic program (i.e., exploit) to modify, and hence, replicate the software application on any device. This automation removes the need for the attacker to distribute and publish his knowledge about how to mount the attack because the exploit does this job for him.
A second common attack scenario on unique IDs is emulation. Virtual machines (such as VMware™ available from VMWARE INC of Palo Alto, Calif., Xen™ available as freeware from Xen.org, and others) are technologies that mimic the hardware devices beneath an operating system (OS) with a software layer. Such emulation is typically so sophisticated that all device drivers and kernel services are fully supported in software. In this manner, any unique IDs may also be easily changed or replicated with virtual machine technology.
A third common attack on unique IDs is a simple re-implementation of a system or sub-system that performs the node-locked actions with the node-locking protections removed. Following a simple observation of the unique IDs that are in use for the system under attack, an attacker may typically re-implement the parts that use the unique ID in assembly code, C programming, or the like.
It is, therefore, desirable to provide a system and method for overcoming problems associated with the traditional approach to node-locking.